Is this abusing Field to get a type object (i.e., the class I asked for in the previous PR)? If not, I don't understand why a) it's a Field, and b) it has no name. (If it is, obviously this just further reinforces my belief that that class should exist.)

Nope, in a later PR I actually start using the name parameter. It wasn't needed at this time to make existing tests pass.

I think I'm still missing something; how can a field not have a name? I don't understand what that would mean.

Before this PR the AST never stored the name of the argument to the method (it would just generate them). Now we have the ability to store it, but no generator actually reads the value, so it's inconsequential what the value is. In the later PR we read from those values: #425

Sorry, I'm still not following.

A Field is described as being a field of a class. That suggests to me that the return value is intended to be used directly as a class field in one of the generated parameter objects (if I'm wrong about that, then Field doesn't seem like the right type). What does it mean to have a field in a class without a name? I don't understand, conceptually, what that would mean in any of the languages Pigeon generates. So I do not understand what this return object is actually representing. I.e., if asked I could not, based on having read this implementation, write a coherent declaration comment that explains what—conceptually, not in terms of the class and values—this method returns.

Either this makes sense in some way I don't currently understand, in which case it needs a clear comment, or the return value is currently expressing something which can't exist, which seems very confusing and thus not something that should be done.

Ooookay, I think I understand. There are 2 issues here:

1. I'm using a Field here since an Argument has the exact same data as a Field. I twisted the meaning of a pigeon.Field and it is clashing with your Schema for Field and the docstring for pigeon.Field
2. The incompleteness of the AST. You can see the AST as a representation of the input source code, and if you look at it that way, any discrepancy in information is a flaw. Or you can look at the AST as the input to the generators, where any unused data is waste. Third, it has the role of being the input to the validator that gatekeepers the generators. It has to navigate those 3 responsibilities. It is complete today as much as it needs to be to implement the features we've delivered. There will probably always be gaps until we find the funding to fully flesh out more features.

Here's what we should do. I should introduce an Argument object here and use that instead. Sound good?

I twisted the meaning of a pigeon.Field and it is clashing with your Schema for Field and the docstring for pigeon.Field

I'm confusing why you are calling it "my" schema. It's identical to the one-sentence docstring—which you wrote, presumably—for Field. This isn't some esoteric meaning I've invented for it.

It has to navigate those 3 responsibilities.

You've missed an important responsibility, which is making sense to someone reading the code. If the representation isn't comprehensible to another reader—for instance, because it's abusing one concept to partially represent a different concept just to save a few lines of code—then that representation is problematic.

Here's what we should do. I should introduce an Argument object here and use that instead. Sound good?

That's fine, assuming there's a reason Field and Argument being different is actually useful. Otherwise just calling Field Variable instead, and changing its description, seems more straightforward.